<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'New ideas',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		Between my utter lack of enthusiasm for coursework and the very long reading assignment this week, I&apos;ve been struggling to get the material read so I could answer the discussion assignment for the week.
		I bought some time by focussing on my other discussion assignment until I could get everything read, but I was out of time tonight.
		I finished the material though, and the answer to the question wasn&apos;t even covered.
		Why are we being asked things we were never taught?
		Minutes before midnight, I got this submitted:
	</p>
	<blockquote>
		<p>
			Either I entirely missed it, or this wasn&apos;t covered in the reading assignment.
		</p>
		<p>
			Anyway, one way that the ancients used trigonometry to improve accuracy when processing large numbers was to make use of lookup tables and knowledge of logarithm mechanics (Lamb, 2013).
			They knew that the log<sub>b</sub>(a*c) is equal to log<sub>b</sub>(a)+log<sub>b</sub>(c).
			Addition is easier than multiplication, so they could look up log<sub>b</sub>(a) and log<sub>b</sub>(c) on their lookup  tables, add them together, and look up what number had log<sub>b</sub>() of the resulting number for their solution.
			From the sounds of it, different trigonometric functions were used based on what numbers you had to work with.
			For some numbers with some functions, the value provided is too small to be useful for accuracy.
			There just isn&apos;t enough precision, unless the table you are working with has a lot of digits of the output listed.
			In those cases, you&apos;d simply choose a different function, one better suited to the numbers you needed to work with.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Lamb, E. (2013, September 12). 10 Secret Trig Functions Your Math Teachers Never Taught You - Scientific American Blog Network. Retrieved from <a href="https://blogs.scientificamerican.com/roots-of-unity/10-secret-trig-functions-your-math-teachers-never-taught-you/"><code>https://blogs.scientificamerican.com/roots-of-unity/10-secret-trig-functions-your-math-teachers-never-taught-you/</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest log</h2>
	<img src="/y.st./source/y.st./static/img/CC_BY-SA_3.0/minetest.net./weblog/2018/03/18.png" alt="Smelting my metals" class="framed-centred-image" width="800" height="600"/>
	<p>
		I started working on the drop-handling code for <code>drop_hack</code>, but pretty soon, I remembered my new <code>minestats</code> feature that counts drops without diggers.
		<code>drop_hack</code> would set that off with every attempt to retry the drop in the players&apos; favour.
		My initial design just won&apos;t work.
		In fact, the more I think about it, I&apos;m not sure <strong>*any*</strong> design would work.
		I mean, I could use a custom node drop calculator that adjusts probabilities directly instead of trying the drop again, but then <code>minestats</code> would never get the message that the drop had or had not occurred.
		Modern <code>minestats</code> won&apos;t support such behaviour, which in all honesty, is a feature of <code>minestats</code>, not a bug I can correct.
		I mean, I could <strong>*easily*</strong> &quot;correct&quot; this behaviour, but because it&apos;s the way things really should be, I&apos;m not going to.
		This mod simply isn&apos;t an option unless I find a way to bypass it in ...
		Oh, my, I just realised that the feature only gets in the way when trying to prevent drops, which a player very well may want to do.
		For example, <code>minestats</code> aside, it&apos;s annoying when gravel drops flint.
		Flint is useless unless you like building fires, while gravel is great for building paths in certain types of areas.
		When gravel drops itself though, <code>minestats</code> doesn&apos;t count it, so throwing that result out and re-rolling the virtual die to try to get flint causes no problem.
		It&apos;s only if we roll flint and try to re-roll for gravel that the problem occurs.
		After starting to write about how I couldn&apos;t build this mod, I ironically got the main functionality done.
		It still needs an interface so players can turn it on and off per item though.
		For now, it&apos;s locked in the on position for all items, whether players want it or not.
	</p>
	<p>
		I was thinking today about the <code>yellow</code> mod, as well as a sort of hammerspace chest node I want to program.
		Every time I got to program them though, I quickly stop, if I even get started at all.
		I think the reason is that I know they&apos;ll be used to cheat.
		In fact, <strong>*I*</strong> would use them to cheat, even if no one else did.
		I would bring a chest with me to access my personal hammer space, and bring a bed to set temporary, one time use warp points so I could return to base to drop stuff off and come right back.
		I don&apos;t want that sort of use.
		It&apos;s an abuse of what those nodes are capable of and makes the game too easy.
		I started trying to come up with methods of penalising such cheating.
		For example, the most obvious solution is to have those nodes drop only <strong>*some*</strong> of the materials used to craft them, instead of the whole node.
		That would technically put those nodes into the category of nodes <code>minestats</code> should count drops for, but logically, that shouldn&apos;t be a stat to shoot for increasing.
		(Now that I think on it, I could use probabilities in my favour to bypass this and sometimes drop all the materials used, while players would still be deterred from knowingly placing such nodes in temporary locations.)
		I don&apos;t think that gives enough of a deterrent though, and it penalises players that end up moving too much, particularly players that accidentally place it a node off and never wanted it where they put it and players that redecorate.
		The nodes are still effectively in the same place as before, but they&apos;ve gotten moved over a few nodes or whatever.
		There shouldn&apos;t be a penalty for that.
		Fixing the problem of <code>minestats</code> semantics, my next idea was to have those nodes drop nothing.
		At all.
		If you remove such nodes, you lose all the material that went into them.
		Again though, it seems too harsh.
	</p>
	<p>
		I figured it out though: the perfect idea.
		After placing such a node, a player is given a downward-counting counter.
		It&apos;ll probably be set to one hundred or something.
		Each time they mine something countable, the counter goes down.
		Until it hits zero, they&apos;re not able to remove such nodes from the world.
		They have to leave it and come back later.
		I started thinking about how to use <code>minestats</code>&apos; player-specific update notifier to build a sort of ticker, but then I remembered that the work was already done.
		The $a[API] function was initially intended to register a function that would receive info on what stats got increased, but simplicity ended up winning over flexibility.
		The $a[API] only calls that function telling it what player&apos;s stats changed, not what stats changed.
		It was a design decision that I sometimes regret and sometimes intend to fix someday, but the thing is <strong>*already*</strong> exactly the ticker I need it to be for this particular feature.
		I just need to set up the counter to go with the ticker.
		This anticheat feature will prevent the outright cheating that I fear while still allowing normal use; it even allows some of the questionable behaviour that isn&apos;t what the nodes are meant for, but is kind of okay.
		For example, I plan to still set up a sort of temporary camp in one of the caves with lava.
		Then when I&apos;m done mining there, I&apos;ll pick up my stuff and go.
		Still, I&apos;ll be leaving it there for a while and use it repeatedly, not use it as a one-time warp point.
		I will probably try to merge the ticking behaviour from both mods, either by creating a third mod both depend on or by outright merging the two mods to form a bigger one.
	</p>
	<p>
		I&apos;ve also been thinking about the recipe for the hammerspace chest.
		For the <code>yellow</code> mod, the bed recipe is very similar to the one from the <code>beds</code> mod, but with a slight change.
		I think it might be best to do something similar with the recipe for the hammerspace chest.
		I was thinking that including iron in the recipe was a must, because everything ownable in this subgame includes iron.
		However ... you don&apos;t actually own the hammerspace chest when it&apos;s in the world (as opposed to in your inventory).
		It allows each player to access their own private hammerspace.
		You own the hammerspace, but not the chest node.
		I might not put steel in the recipe at all.
		Anything goes.
	</p>
</section>
END
);
